Get flight duration and live ETA via API. AirLabs returns scheduled block time from the Routes Database and real-time estimated arrival, delay and status from the Flight Info and Schedules APIs
Two questions come up in almost every product built on flight data. Before a flight: how long is it? During a flight: when will it actually land? A booking flow wants to show "7h 14m" next to a fare. A flight tracker wants a live countdown to arrival. An airport-transfer service wants to dispatch a driver against the real landing time, not the one a passenger typed in three days ago.
The naive answer — take the great-circle distance between two airports and divide by a cruise speed — is always wrong, and usually wrong by a lot. It ignores taxi-out and taxi-in, departure and arrival routing, step climbs, headwinds and tailwinds, holding, and the block-time padding airlines build into their schedules. A 500 km hop can block ninety minutes; a transatlantic crossing can vary by an hour depending on the jet stream. Real duration and real ETA come from operational data, not geometry.
This guide covers both numbers on the AirLabs platform: scheduled duration (block time) from the Routes Database, and live estimated arrival with delay and status from the Flight Info and Schedules APIs. Every duration value below is returned in minutes, and every time comes in both local-airport and UTC form.
The first number is the planned one — how long this flight is supposed to take, published in the timetable. That is block time: gate to gate, including taxi. The Routes Database carries it directly as a duration field, alongside the scheduled departure and arrival times and the days the route operates.
https://airlabs.co/api/v9/routes?dep_iata=CMB&arr_iata=AUH&api_key={KEY}
[
{
"airline_iata": "UL",
"flight_iata": "UL2265",
"dep_iata": "CMB",
"dep_time": "02:50",
"dep_time_utc": "21:20",
"arr_iata": "AUH",
"arr_time": "05:50",
"arr_time_utc": "01:50",
"duration": 270,
"days": ["mon", "wed", "sat"],
"aircraft_icao": "A320"
}
]duration is 270 — four and a half hours of scheduled block time, already accounting for the padding and taxi that a distance calculation would miss. Because the Routes Database is keyed by airline and airport pair, you can answer "how long is a typical CMB→AUH flight?" without a specific date or flight in progress — ideal for a booking form, a route comparison, or a "flight length" label shown before anything has departed.
Note the two time formats. dep_time and arr_time are in each airport's local time; dep_time_utc and arr_time_utc are UTC. Always compute duration from the UTC pair (or use the duration field directly) — subtracting local times across a timezone boundary is how you end up displaying a "-3 hour" flight. If your product handles a lot of cross-timezone logic, the time zones list is worth keeping nearby.
Scheduled duration answers "normally." Once a specific flight is in the air, you want "actually" — the current estimated arrival. The Flight Info API returns a single flight by number with its live status, the scheduled and estimated times, the delay, and the same duration field.
https://airlabs.co/api/v9/flight?flight_iata=AA6&api_key={KEY}
{
"flight_iata": "AA6",
"dep_iata": "OGG",
"dep_time": "2021-07-21 18:50",
"dep_time_utc": "2021-07-22 04:50",
"arr_iata": "DFW",
"arr_time": "2021-07-22 07:04",
"arr_time_utc": "2021-07-22 12:04",
"arr_estimated": "2021-07-22 07:20",
"duration": 434,
"delayed": 16,
"dep_delayed": null,
"arr_delayed": 16,
"status": "en-route",
"lat": 33.45,
"lng": -118.73,
"alt": 10668,
"speed": 942
}Three time concepts do the work here, and it is worth being precise about them because mixing them up is the most common bug in flight-time features:
arr_time) — the time the airline published. The commitment, and the baseline for any delay.arr_estimated) — the current best forecast, updated in real time. If the flight is on time, estimated equals scheduled; if it slips, estimated moves forward. This is your ETA.delayed, split into dep_delayed / arr_delayed) — the difference in minutes between scheduled and estimated. Here the flight is running 16 minutes late into DFW.The status field (scheduled, en-route, landed, cancelled) drives the state of any countdown or board, and because Flight Info also returns the live lat, lng, alt and speed, you can render a progress bar or map position alongside the ETA rather than just a bare timestamp.
For a whole airport at once rather than a single flight, the Schedules API returns the same dep_estimated / arr_estimated / delayed / duration fields for every current departure and arrival — the right call when you are building a live board and want every flight's ETA in one request instead of polling flights individually.
It is tempting to compute duration yourself from airport coordinates. The great-circle distance between two airports is useful — as a lower bound, a sanity check, or a map arc — and you can derive it from the lat/lng fields in the Airports Database. We cover that calculation in full in the great-circle distance between airports guide.
But great-circle time is a floor, not an estimate. It assumes a straight line at constant cruise speed with no taxi, no climb or descent profile, no air-traffic routing, and no wind. Real flights add fifteen to forty minutes of ground and terminal-area time before you even reach cruise, and winds alone can swing a long-haul block time by an hour. Use great-circle for distance and geometry; use the duration field for how long the flight takes, and arr_estimated for when it lands.
A single helper can return everything a product needs to show for a flight — its typical length, its live ETA, and how late it is running:
import requests
API_KEY = "YOUR_API_KEY"
BASE = "https://airlabs.co/api/v9"
def flight_time(flight_iata):
r = requests.get(f"{BASE}/flight", params={
"flight_iata": flight_iata,
"api_key": API_KEY,
})
f = r.json().get("response")
if not f:
return None
mins = f.get("duration")
return {
"route": f"{f['dep_iata']} -> {f['arr_iata']}",
"duration": f"{mins // 60}h {mins % 60:02d}m" if mins else "n/a",
"scheduled_arrival": f["arr_time"],
"estimated_arrival": f.get("arr_estimated", f["arr_time"]),
"delay_min": f.get("arr_delayed") or 0,
"status": f.get("status"),
}
print(flight_time("AA6"))
# {'route': 'OGG -> DFW', 'duration': '7h 14m',
# 'scheduled_arrival': '2021-07-22 07:04',
# 'estimated_arrival': '2021-07-22 07:20',
# 'delay_min': 16, 'status': 'en-route'}Four fields, one call, and the same ?api_key= auth as the rest of the platform. Swap the flight number and it works for any flight worldwide.
Booking and search UIs. Show flight length ("7h 14m") next to each option using the Routes duration, before anything is airborne. It is one of the details travellers scan for, and it comes free with the route lookup.
Flight trackers and status pages. A live countdown to arrival driven by arr_estimated, a progress bar from the live position, and a delay badge from arr_delayed. The status field colours the whole thing.
Airport transfers and ground transport. Dispatch and pickup timing against the real arr_estimated, not the scheduled time — the difference between a driver waiting forty minutes and arriving as the passenger clears the gate.
Logistics and operations dashboards. Ground handling, catering, crew and gate planning keyed to estimated arrival across a whole airport via the Schedules API.
Proactive notifications. When an ETA moves, tell the user. The Flight Alert API pushes a webhook on any change to arr_estimated, status or delay fields, so you notify on the change instead of polling for it.
To keep the scope honest:
duration field is the direct answer, available without a live flight.arr_estimated, delayed and status from the Flight Info API (single flight) or the Schedules API (whole airport) give the real-time forecast.What this is not is a proprietary predictive-arrival engine modelling winds aloft and ATC flow. The estimated times AirLabs returns come from airline and airport operational feeds — the same source that drives departure boards — surfaced as clean, queryable fields. For the overwhelming majority of travel products, a feed-based arr_estimated is exactly the ETA you want, and it arrives without you running a meteorological model.
Duration is always minutes. 434 means 7h 14m. Format it once in a helper (as above) and never show a raw minute count to a user.
Cache by volatility. Route duration and scheduled times barely change — cache them for hours or days. Live arr_estimated changes as the flight operates — cache it for seconds, not minutes, or you will show a stale ETA.
Use UTC for math, local for display. Every time field has a _utc twin (and a _ts unix timestamp). Compute with UTC or the timestamp; show the local value to the user.
Handle missing values. Delay fields are null when a flight is on time, and duration can be absent for sparse routes. The helper above defaults gracefully with .get() — do the same in production so an on-time flight never renders as "null minutes late."
Once duration and ETA are wired in, the neighbouring endpoints compose naturally. The Schedules API turns a single ETA into a full live board; the Flight Delay API filters to just the flights running late; the Flight Alert API pushes ETA changes to your backend; and for building on-time-performance analytics from these same fields over time, the flight performance data guide is the companion read.
You can try it right now without any obligation! Get a free flight API plan and see for yourself that we have exactly the data you need!
If you need more information, don't hesitate to contact us. We are always happy to chat with our customers and are sure to find a customized solution for each request.
Explore AirLabs, or create an account instantly and start using API.
Get FREE API Key